FHIR Implementation Guides

Base FHIR is deliberately under-specified. Patient has an optional name, optional identifier and optional gender, because it has to work in every country on earth. That flexibility means two conformant FHIR servers can be entirely unable to exchange data.

An implementation guide closes the gap. It states, for one context, which resources are used, which elements are mandatory, which terminology is bound to which field, and which interactions a server must support.

Nothing interoperates against "FHIR". Systems interoperate against an implementation guide. This is the single most useful sentence to repeat during procurement.

What an IG contains

An IG is itself a set of FHIR conformance resources, published as a website plus a machine-readable package.

Resource	States
`ImplementationGuide`	The package itself — dependencies, version, contents
`StructureDefinition`	A profile: constraints on a resource (cardinality, required elements, fixed values) or an extension
`ValueSet`	The permitted codes for a coded element
`CodeSystem`	A code system defined locally (use sparingly — prefer existing ones)
`ConceptMap`	Translation between code systems
`SearchParameter`	Additional search capability
`OperationDefinition`	A custom operation (`$match`, `$everything`, …)
`CapabilityStatement`	What a conformant server must support
`Questionnaire` / `QuestionnaireResponse`	Structured data capture forms
Examples	Instances that validate against the profiles

The three constraint decisions

For every element, an IG decides:

Cardinality — is it required (1..1), optional (0..1), forbidden (0..0)?
Terminology binding strength — required (must use a code from the value set), extensible (use one if it fits), preferred, or example. Getting this wrong in either direction is the most common IG defect: required bindings on incomplete value sets block real data; example bindings on everything produce no semantic interoperability at all.
Must-support — the element is not mandatory, but a conformant system has to be able to handle it if present. mustSupport needs a written definition of what "support" means in your IG; the base specification deliberately leaves it to you.

Major published implementation guides

All Tier 1 (published by HL7 or an accredited affiliate) unless noted. Last verified 2026-08-24.

International

IG	Scope	URL
International Patient Summary (IPS)	A minimal, non-negotiable summary set for unplanned cross-border care: problems, allergies, medications, plus optional sections	https://hl7.org/fhir/uv/ips/
International Patient Access (IPA)	What a patient-facing app can expect from any server, internationally	https://hl7.org/fhir/uv/ipa/
SMART App Launch	Authorisation and launch context for FHIR apps	https://hl7.org/fhir/smart-app-launch/
Bulk Data Access	Population-level export	https://hl7.org/fhir/uv/bulkdata/
SDC (Structured Data Capture)	Forms: `Questionnaire`, population and extraction	https://hl7.org/fhir/uv/sdc/
CPG (Clinical Practice Guidelines)	Representing computable guidelines — the substrate for SMART Guidelines	https://hl7.org/fhir/uv/cpg/
mCODE	Minimal common oncology data elements	https://hl7.org/fhir/us/mcode/
SMART Health Cards / Links	Verifiable clinical data for the holder	https://hl7.org/fhir/uv/smart-health-cards-and-links/

United States

Useful reading even outside the US, because they are the most thoroughly worked-through examples available.

IG	Scope	URL
US Core	The baseline US profile set; the model most other national IGs are compared against	https://hl7.org/fhir/us/core/
Da Vinci	Payer–provider workflows: prior authorisation, coverage, quality measures	https://hl7.org/fhir/us/davinci-pas/
CARIN Blue Button	Consumer access to claims data	https://hl7.org/fhir/us/carin-bb/
Gravity	Social determinants of health data	https://hl7.org/fhir/us/sdoh-clinicalcare/

WHO SMART Guidelines

WHO publishes computable guideline content as FHIR IGs — immunization, antenatal care and others, at varying stages of maturity. See SMART Guidelines for the method and https://www.who.int/teams/digital-health-and-innovation/smart-guidelines for the current catalogue. Check publication status per guideline: some are published, some are in active development, and the difference matters if you are writing a procurement specification.

National IGs

Many countries publish national FHIR IGs — among them Australia (AU Core), Canada (CA Core+), the Netherlands (Nictiz), Switzerland (CH Core), India (NRCES), and members of the European HL7 Europe programme. HL7 affiliates are listed at https://www.hl7.org/Special/committees/international/leadership.cfm, and published IGs are indexed at https://fhir.org/guides/registry/ and https://simplifier.net/.

Needs verification per country before citing: national IG catalogues change frequently and several are hosted on national health-authority domains rather than hl7.org.

Writing your own

Most countries need a national IG. Most programmes do not — they need a profile set that depends on the national IG.

The process

1. Use case            One exchange, one pair of actors, one workflow
        │
2. Data elements       From the clinical workflow / DAK, not from FHIR
        │
3. Map to resources    Which FHIR resource carries each element
        │
4. Profile             Cardinality, must-support, extensions where truly needed
        │
5. Terminology         Value sets and binding strengths
        │
6. Examples            Real-shaped instances that validate
        │
7. Publish             IG Publisher → website + package
        │
8. Test                Validator, Touchstone / Inferno, connectathon
        │
9. Version and govern  Who may change it, and on what cycle

Step 2 is the one teams skip. Starting from FHIR resources rather than from the workflow produces an IG that models the standard rather than the care.

Rules that save rework

Derive, don't invent. Profile the international IG (IPS, IPA) or a mature national one rather than starting from base FHIR.
Extensions are a last resort. Search the base spec, the extension registry and existing IGs first. Every extension is a permanent integration cost.
Don't define a CodeSystem you don't own. Bind to SNOMED CT, LOINC, ICD or a genuinely national code system.
Publish the CapabilityStatement. Without it, "supports the IG" is unfalsifiable.
Version explicitly, with a stated policy for breaking changes, and never change a published version in place.
Ship examples that validate. An IG whose own examples fail validation will not be implemented correctly.

Tooling

Tool	Role
FHIR Shorthand (FSH) + SUSHI	Author profiles as concise text rather than raw JSON — the current standard practice
IG Publisher	HL7's official build tool: renders the site, builds the package, runs QA
FHIR Validator	Validates instances against profiles
Simplifier.net	Hosting, collaboration and registry
Inferno / Touchstone	Conformance test suites

Consuming an IG

Before committing to one in a contract:

Read its CapabilityStatement and check every interaction you need is there
Check the FHIR version it targets (R4, R4B, R5) and whether your server matches
Check its publication status — draft, trial-use (STU), or normative
Check its dependencies, and whether those are stable
Run its examples through a validator against your server
Find out who maintains it and on what cadence

References

FHIR implementation guide registry — https://fhir.org/guides/registry/
HL7 FHIR specification — https://hl7.org/fhir/
FHIR Shorthand — https://hl7.org/fhir/uv/shorthand/
SUSHI and IG Publisher documentation — https://fshschool.org/
Simplifier — https://simplifier.net/
Inferno — https://inferno-framework.github.io/

What an IG contains​

The three constraint decisions​

Major published implementation guides​

International​

United States​

WHO SMART Guidelines​

National IGs​

Writing your own​

The process​

Rules that save rework​

Tooling​

Consuming an IG​

References​